<html>
<head><meta charset="utf-8"><title>testing-release-channel · t-release · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/index.html">t-release</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html">testing-release-channel</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="235250769"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235250769" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235250769">(Apr 19 2021 at 21:12)</a>:</h4>
<p>Hi you lovely people!</p>
<p>A few weeks ago I posted a proposal for a new release channel, "testing", to <a href="http://internals.rust-lang.org">internals.rust-lang.org</a>: <a href="https://internals.rust-lang.org/t/the-case-for-a-new-relese-channel-testing/14412/1">https://internals.rust-lang.org/t/the-case-for-a-new-relese-channel-testing/14412/1</a>. The purpose of it would be to enable more wide-spread testing of _particular_ unstable features in environments where nightly isn't generally viable/acceptable. After a lot of good discussion, I think it's now at the point where writing an RFC is starting to make sense. However, Josh (Triplett) pointed out (see last post; number 32) that it's not entirely clear which teams would need to sign off on this, and that that would be good to get clarity on first. Since this seems pretty squarely within the purview of the release team, I figured I'd check with you all first what you think the process for considering this proposal should be like?</p>



<a name="235254317"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235254317" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235254317">(Apr 19 2021 at 21:39)</a>:</h4>
<p>Hm. I do think this is a question for the release team, primarily, in terms of FCP, though I'm not necessarily opposed to other teams also being on the list.</p>
<p>I just read the thread, so I may have missed something, but I think one thing I didn't see discussed is that for many of the features I think this would be useful, I would expect users to not want to "temporarily" migrate to said feature, only for it to go away in X weeks - and potentially only return in several months.</p>
<p>It is currently true that we (the project) support only the latest stable, and even there primarily only for security fixes; in some sense the latest nightly is the most likely to have the least bugs. I think the proposal as it stands feels like it would encourage users to upgrade to testing 1.x and pin that - which is not great, and feels like they'd not likely volunteer to be on a less good compiler indefinitely.</p>
<p>I agree that the underlying problem of getting features tested exists, and is worth solving, though.</p>



<a name="235254363"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235254363" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235254363">(Apr 19 2021 at 21:39)</a>:</h4>
<p>Happy to leave this feedback on the internals thread, too.</p>



<a name="235256138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235256138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235256138">(Apr 19 2021 at 21:57)</a>:</h4>
<p>Yeah, I agree with you that the users most likely to want exactly what testing provides are also unlikely to want to migrate "back and forth" for a feature. This is why I'd like to recommend that _if_ the decision for a feature is to stabilize it, it should be left on testing until the stabilization hits beta (and therefore also hits testing). The idea for the time period is that after X weeks, a decision will be made either to stabilize or to throw it back to design, not for it to just silently move back to nightly-only. And since it _is_ an unstable features, it _has_ to be possible to reject a given proposal, and users should be aware of that. I think all we can do to make the process more palateable is to at least make sure that _if_ it's stabilized, _then_ there's no gap in use.</p>
<p>I agree that it's a sort of awkward compromise — it's not quite as stable as stable, and not quite as up-to-date as nightly — but I also haven't been able to come up with a better one. There's this (seemingly) fundamental trade-off between the guarantees of stable and the nature of unstable features that I've only been able to square by saying "testing has curated unstable features available and is released with beta to get backports". I don't _think_ users will generally _want_ to be on testing unless they very specifically eagerly want to test a particular unstable feature. Which is what testing would be for. If they just want unstable features, nightly _will_ be better for them. If they just want stability, stable will be better for them. Testing is for the users who want stability but _need_ (or at least very strongly desire) a particular unstable feature, and want to help make that a reality on stable. I feel like it's unlikely anyone would actually stay on testing for any longer period of time. The design as proposed is also sort of tailored towards making choosing testing for anything but what it was designed for a bit of a pain (see the <code>-Zallow-features</code> requirement for example).</p>
<blockquote>
<p>Happy to leave this feedback on the internals thread, too.</p>
</blockquote>
<p>I think either venue is fine. Ultimately, assuming this ends up with me writing an RFC, I'll make sure to incorporate the input from both places :)</p>



<a name="235260488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235260488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235260488">(Apr 19 2021 at 22:38)</a>:</h4>
<p>Interesting. I had not picked up on the bit that testing would be only used on a path to stabilization; that is something we have done before with beta by fully stabilizing some feature but then reverting it before releasing the corresponding stable, usually for just one release cycle. I don't know how much value we got out of that, but it wouldn't really be hard to go into that in a more complete way.</p>
<p>I think beta is the wrong place to do this, though. Ultimately it feels like we want to actually semi-stabilize the toolchain, with the full series of beta backports, written compatibility notes etc - and for that you really do want stable. I'm not actually sure we would lose much from our stability promise if you could opt-in to a subset of nightly features on stable (or create a concurrently run testing channel); but then, I myself pretty much always use nightly - and find it plenty stable.</p>



<a name="235260690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235260690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235260690">(Apr 19 2021 at 22:40)</a>:</h4>
<p>It would be interesting to get a sense of the kind of toolchains used at the suggested audience for this channel (i.e. big corps or other large projects), and whether they'd prefer to base off of stable or a rolling nightly. I'd personally likely lean towards recommending a rolling nightly; I think there are many projects doing that today, and it definitely helps us uncover bugs.</p>



<a name="235314732"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235314732" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Pietro Albini <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235314732">(Apr 20 2021 at 09:33)</a>:</h4>
<p>I expressed that already on internals, but I'm not convinced about using beta either: it's reliability story goes from same as nightly to same as stable slowly over the 6 weeks, and then it immediately drop off back at as reliable as nightly</p>



<a name="235376298"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235376298" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235376298">(Apr 20 2021 at 16:45)</a>:</h4>
<blockquote>
<p>testing would be only used on a path to stabilization</p>
</blockquote>
<p>Ah, I wasn't thinking _quite_ that strictly. Rather, the idea would be to only explicitly opt-into features that we want added testing at larger scale for. They don't necessarily have to be "almost stabilized", but I do think they should be in a place where the consensus is "stabilize as long as experience with the feature is positive", or something along those lines.</p>
<blockquote>
<p>.. beta ..</p>
</blockquote>
<p>I honestly don't know where the best place to piggy-back this off of is. The reason I didn't want to go full stable is that it would mean a required 12 weeks before a new feature can be tested, and before fixes to that feature become available for testing, which is a long time. I suppose we _could_ backport into testing, but that seems like a game we probably don't want to get into.</p>
<p>Pietro's point about beta starting out as nightly was and is a good one. One option to straddle the difference is to make testing be beta + X weeks. That is, testing doesn't bump to beta until X weeks after the nightly-to-beta promotion, and then on any subsequent rc. The process is a bit more complicated, but it would avoid some of the "drop" in stability.</p>
<blockquote>
<p>.. rolling nightly ..</p>
</blockquote>
<p>At AWS, we currently _only_ use stable. I could try to argue for a rolling nightly internally, but I think that would be an uphill battle. Specifically, I think the concern would be that nightly is more likely to have _new_/undiscovered bugs than stable is. I don't have any concrete data for this, it just _seems_ inherently true — nightly changes, stable does not, so nightly will have more changes that haven't been widely tested (some that may literally _just_ have landed), and thus may be buggy. In trying to gather data, I took a look at <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3Aregression-from-stable-to-nightly"><code>regression-from-stable-to-nightly</code></a> vs. <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3Aregression-from-stable-to-beta"><code>regression-from-stable-to-beta</code></a> vs. <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3Aregression-from-stable-to-stable"><code>regression-from-stable-to-stable</code></a>, but it's a bit of a hard-to-analyze dataset since stable gets way more testing (and thus more reports) than nightly. I was surprised to find that they each have roughly the same number of reported issues, though I suspect that's again because stable has so many more users.</p>
<p>Part of the challenge with rolling nightly is that there aren't "good snapshots". Each nightly is likely to have _some_ know problem that has since been fixed. And across a code base as large as AWS', chances are most such problems are exercised. The fix is to update to the next nightly, but that may either not be out yet or if it is, may have some _other_ issue that breaks _another_ internal package. The upshot of stable (and most betas) is that they are snapshots that become _overall_ stable due to being change-frozen + getting backports. That'd be hard to give up.</p>



<a name="235376663"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235376663" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235376663">(Apr 20 2021 at 16:47)</a>:</h4>
<blockquote>
<p>I was surprised to find that they each have roughly the same number of reported issues, though I suspect that's again because stable has so many more users.</p>
</blockquote>
<p>and also because stable-to-nightly bugs turn into stable-to-stable bugs if they aren't fixed</p>



<a name="235378925"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235378925" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235378925">(Apr 20 2021 at 17:02)</a>:</h4>
<p>Also, I think _if_ we ended up basing testing off of stable, it should still be its own channel, not "stable with RUSTC_BOOTSTRAP". I think <span class="user-mention" data-user-id="232545">@Joshua Nelson</span> has more thoughts on that too.</p>



<a name="235382095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382095">(Apr 20 2021 at 17:24)</a>:</h4>
<p>my main concern with "stable with RUSTC_BOOTSTRAP" is it lets you use <em>any</em> unstable feature, including ones that are never meant to be stabilized</p>



<a name="235382357"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382357" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382357">(Apr 20 2021 at 17:26)</a>:</h4>
<p>honestly for the use case of "we plan to stabilize this but want more testing" I wonder if it needs a new channel at all - maybe we could just add a stable <code>--allow-features</code> flag that only permits certain features?</p>



<a name="235382461"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382461" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382461">(Apr 20 2021 at 17:27)</a>:</h4>
<p>and those features are still unstable and can change release to release, we don't give a <em>guarantee</em>, but we try not to break things unecessarily</p>



<a name="235382488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382488">(Apr 20 2021 at 17:27)</a>:</h4>
<p>that would be useful for things like <a href="#narrow/stream/219381-t-libs/topic/When.20can.20we.20do.20a.20partial.20stabilization.20of.20Neon.20intrinsics.3F">https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/When.20can.20we.20do.20a.20partial.20stabilization.20of.20Neon.20intrinsics.3F</a></p>



<a name="235382517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382517">(Apr 20 2021 at 17:27)</a>:</h4>
<p>That's an interesting idea.. Though it does still mean that people can opt out of _some_ of the stability guarantees of stable — is that something we want to enable?</p>



<a name="235382762"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235382762" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235382762">(Apr 20 2021 at 17:29)</a>:</h4>
<p>I have no opinion here, my perspective is from people using nightly features on <a href="http://docs.rs">docs.rs</a> as if they're stable and the problems that causes for rustdoc. Rustdoc doesn't have any features that need more testing, only bug fixes.</p>



<a name="235388643"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235388643" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235388643">(Apr 20 2021 at 18:08)</a>:</h4>
<p>I think the misunderstanding around nightly may be that we don't generally backport to stable/beta non-regression fixes, so nightly is more likely to have bugs in general fixed. This can sometimes include bugs in recently stabilized features, too, so those may roll out onto stable.</p>
<p>What this ultimately means is that as written, I suspect you'd end up with a lot of backports to this testing branch or whatever being requested - especially right after the branch point, if it's time based.</p>
<p>I think in practice the ideal here is for the branch to be basically a rolling nightly, with manual backports, but with a subset of features "stabilized" - basically, we'd branch off and then continuously backport for the testing period important fixes and changes on nightly. But this is really high overhead, and I don't think we can do this today. Maybe eventually!</p>
<p>I'm not sure whether there's a different solution which yields a sufficient improvement here, as I said, it definitely feels like an important problem to solve</p>



<a name="235399387"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235399387" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235399387">(Apr 20 2021 at 19:16)</a>:</h4>
<p>Yeah, I agree that a rolling testing with backports is probably what we'd ideally want, but as you say, that doesn't feel feasible now (and I suspect probably not for a _very_ long time). I'm imagining, perhaps naively, that we'd only greenlight features for testing if they are in a decently good shape, which should (hopefully) mean that they don't require too many large fixes to be workable, but that may not make a meaningful difference.</p>
<p>I think in my case, a stable <code>--allow-features</code> that can be used to allow particular greenlit features on beta/stable (probably subject to a time limit) would be workable. In practice, as a user, I could then navigate the trade-off space between when to adopt a particular beta (or stable) myself. For example, I could choose to use a beta once it is at least two weeks old, or I could choose to only try the feature on stable even if it is then not subject to all the latest fixes.</p>
<p>The two concerns I have for a stable <code>--allow-features</code> is a) it encourages more use of unstable features on "stable" channels, and b) the release train to beta/stable can get long. B is really present in all the proposals so far. I wonder if the solution there is to allow (though not commit to) backports into beta (not sure about stable) of fixes to greenlit features. For A, I have a hard time evaluating how problematic that is...</p>



<a name="235399720"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235399720" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235399720">(Apr 20 2021 at 19:18)</a>:</h4>
<p>I am against backporting features. If you need to test the latest changes you can use nightly.</p>



<a name="235399840"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235399840" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235399840">(Apr 20 2021 at 19:19)</a>:</h4>
<p>backports always carry a risk and "we want testing of a feature that isn't yet stable" doesn't seem worth it to me at least</p>



<a name="235401049"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235401049" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235401049">(Apr 20 2021 at 19:28)</a>:</h4>
<p>I don't think we can scale backports further than they are today without restructuring that process (likely in a decoupled, but perhaps motivated in part by this) step - there's simply not capacity for approving significantly more backports than we do today, I think. They're already a non-minor time consumption, is my sense.</p>
<p>I think there is significantly more possibility that we could experiment with 'unstable but available on stable/beta', without trying to introduce an alternative channel. I think there would be less expectation with that (as opposed to something 'called' testing) of backports and 'directed' development work.</p>
<p>I think facilitating experimentation for users -- like AWS, I take it, but likely others -- who are <em>OK</em> with breakage from time to time, and have the resources to support that breakage, while providing a core stable 'base' for the rest of the ecosystem is something we're increasingly seeing a desire for. To some extent, the edition system was meant to be one of the ways we deal with these things; it's plausible (though I think unlikely) that e.g. custom test frameworks could stabilize on 202x and be potentially entirely removed in 202y, but it would be pretty unprecedented. </p>
<p>I think in any case, a roughly 3 year timescale for these features in terms of experimentation and work seems unlikely to be really the thing here. I think there's a wider discussion to be had, though, of how much the features that merit this kind of work are not really purely <em>language</em> features, but rather "toolchain" features (e.g., custom test frameworks, some of the cargo support for build system integration, etc.) and that this may change the calculus in terms of what options are available to us.</p>



<a name="235401141"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235401141" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235401141">(Apr 20 2021 at 19:28)</a>:</h4>
<p>I know we've been very hesitant to support #![feature(...)] on stable, though there's no purely technical blockers, as it easily risks a ecosystem split of well-I'm-stable-but-not-really</p>



<a name="235401206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235401206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235401206">(Apr 20 2021 at 19:29)</a>:</h4>
<p>But I think that may be different for features used in sort of a "local" fashion, where they don't necessarily have implications for users of your library, such as custom test frameworks</p>



<a name="235401399"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235401399" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235401399">(Apr 20 2021 at 19:30)</a>:</h4>
<p><span class="user-mention" data-user-id="120054">@Jon Gjengset</span> I think a worthwhile thing here might be to go out and try to collect some data on <em>specific</em> features that might want to use this mechanism, and the extent to which my assumption here is true. If it is true that they could be plausibly deployed "locally" (e.g., within a single Cargo workspace), then that may enable us to have some wiggle room in terms of them being pre-stabilized for trial periods, I think</p>



<a name="235401526"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235401526" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235401526">(Apr 20 2021 at 19:31)</a>:</h4>
<p>That's especially true if they're not features that affect readability of Rust code directly - e.g., rust-analyzer and editors don't need to learn new syntax, users aren't confronted with unexpected functionality -- generally speaking, native-feeling features.</p>



<a name="235402170"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235402170" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235402170">(Apr 20 2021 at 19:35)</a>:</h4>
<p>Those are all excellent points, thank you. I'll go think for a bit <span aria-label="+1" class="emoji emoji-1f44d" role="img" title="+1">:+1:</span></p>



<a name="235432361"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235432361" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235432361">(Apr 20 2021 at 23:35)</a>:</h4>
<p>Somewhat related, I think whatever the next proposal is will have to deal with <a href="https://blog.rust-lang.org/2014/10/30/Stability.html#why-not-allow-opting-in-to-instability-in-the-stable-release">https://blog.rust-lang.org/2014/10/30/Stability.html#why-not-allow-opting-in-to-instability-in-the-stable-release</a></p>



<a name="235436161"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235436161" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235436161">(Apr 21 2021 at 00:17)</a>:</h4>
<p>I think this is what I was getting at with the "not a language feature" / "workspace local" problem</p>



<a name="235436248"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235436248" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235436248">(Apr 21 2021 at 00:18)</a>:</h4>
<p>but I agree that getting something which makes it harder to bump your stable version is also definitely a challenge; I'm less worried for larger users who are likely to have the resources to do so, but it is something to address definitely</p>



<a name="235437445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437445">(Apr 21 2021 at 00:33)</a>:</h4>
<p>Alright, I wrote up a "call for samples" of sorts: <a href="https://internals.rust-lang.org/t/survey-of-high-impact-features/14536">https://internals.rust-lang.org/t/survey-of-high-impact-features/14536</a></p>



<a name="235437537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437537">(Apr 21 2021 at 00:34)</a>:</h4>
<p>I'm hoping that might give me a better idea of other features that may fall in the same bucket before I actually propose anything. Would love feedback on the list of "conditions" for eligible features!</p>



<a name="235437787"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437787" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437787">(Apr 21 2021 at 00:37)</a>:</h4>
<p><span aria-label="thumbs up" class="emoji emoji-1f44d" role="img" title="thumbs up">:thumbs_up:</span></p>



<a name="235437896"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437896" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437896">(Apr 21 2021 at 00:39)</a>:</h4>
<p>(I have to sign off for the day, but will check back in tomorrow — thanks for talking through this stuff with me!)</p>



<a name="235437900"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437900" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437900">(Apr 21 2021 at 00:39)</a>:</h4>
<p><span class="user-mention" data-user-id="120054">@Jon Gjengset</span> One "fun piece" to this story is rustbuild, which definitely uses unstable features in Cargo/rustc interaction layer which are sort of in this bucket:</p>
<ul>
<li>-Zbinary-dep-dep (forget name exactly, but it emits sysroot dependencies into .d files for Cargo to know about)</li>
<li>likely some others...</li>
</ul>
<p>In some sense, historically I think that's been the 'proving ground' for Cargo at least over the last few years, though definitely not with <em>all</em> features that get stabilized</p>



<a name="235437934"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235437934" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235437934">(Apr 21 2021 at 00:39)</a>:</h4>
<p>IOW, the answer is "rustc/rustbuild/std is your test ground for these features"</p>



<a name="235438040"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235438040" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235438040">(Apr 21 2021 at 00:41)</a>:</h4>
<p>and honestly, for major -- essentially vendors -- like it sounds AWS is, where there's essentially a "toolchain team" (even if it's just one person) upgrading the compiler, maybe RUSTC_BOOTSTRAP for this sort of feature is not the end of the world. I'm not sure how I feel about that. But it feels like not a <em>non</em>answer.</p>



<a name="235538352"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235538352" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235538352">(Apr 21 2021 at 16:11)</a>:</h4>
<p>You're not wrong — my instinct is telling me to just go ahead and use the current beta/eventually stable with <code>RUSTC_BOOTSTRAP</code>, and be done with it. But while that would work, I also feel a desire to help see if there's a way the Rust ecosystem can improve here. It may be that the ultimate answer is "recommend <code>RUSTC_BOOTSTRAP</code> for this", but I want to make sure I've at least _tried_ to explore other avenues that the wider ecosystem can get behind.</p>



<a name="235542205"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235542205" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235542205">(Apr 21 2021 at 16:36)</a>:</h4>
<p>For sure! Regardless, I think you don't actually want RUSTC_BOOTSTRAP literally; if that's the recommended path then we should make it nicer regardless, for example with explicit lists of permitted features.</p>



<a name="235542524"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235542524" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235542524">(Apr 21 2021 at 16:38)</a>:</h4>
<blockquote>
<p>if that's the recommended path then we should make it nicer regardless, for example with explicit lists of permitted features.</p>
</blockquote>
<p>isn't that <code>-Z allow-features</code>?</p>



<a name="235542787"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235542787" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235542787">(Apr 21 2021 at 16:40)</a>:</h4>
<p>Perhaps! But I think it's not quite right. In particular, an explicit blessing of a subset of features for intentional experimentation does feel very much like a good idea</p>



<a name="235543024"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235543024" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235543024">(Apr 21 2021 at 16:42)</a>:</h4>
<p>I wonder if <code>-Z allow-recommended-features</code> is a good idea <span aria-label="laughing" class="emoji emoji-1f606" role="img" title="laughing">:laughing:</span></p>



<a name="235545610"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235545610" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235545610">(Apr 21 2021 at 17:00)</a>:</h4>
<p>I also think I would want it to be --foo, rather than an explicitly unstable thing, and come with some guarantees (not strict stability, but documentation, etc.)</p>



<a name="235560565"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235560565" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235560565">(Apr 21 2021 at 18:40)</a>:</h4>
<p>Yeah, the direction I'm thinking is to have <code>--enable-preview-features=</code> (verbose on purpose), which you supply with a list of "preview" features to opt into. "preview", then, would be a subset of unstable features that have explicitly been made so through something like rfcbot/FCP.</p>



<a name="235560596"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235560596" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235560596">(Apr 21 2021 at 18:40)</a>:</h4>
<p>Or maybe <code>--allow-preview-features=</code>?</p>



<a name="235560887"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235560887" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235560887">(Apr 21 2021 at 18:43)</a>:</h4>
<p>Yeah, something to that effect. It may be interesting to draw a comparison with the (continued, partial) rollout of -preview components in rustup, too.</p>



<a name="235560934"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235560934" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235560934">(Apr 21 2021 at 18:43)</a>:</h4>
<p>Please only allow preview features for a fixed time. Otherwise we will get a situation like the web where we can't easily change such features out of fear of breaking builds.</p>



<a name="235561048"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235561048" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235561048">(Apr 21 2021 at 18:44)</a>:</h4>
<p>-preview components can't be required by dependencies unlike "preview" features, so that makes them somewhat different.</p>



<a name="235561169"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235561169" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235561169">(Apr 21 2021 at 18:45)</a>:</h4>
<p>Hm, I think the safeguards of explicit opt-in and being intended as purposeful (for a subset of features), as well as being likely <em>only</em> for workspace-local features, seems to mitigate that risk pretty well IMO. I definitely think that whatever we end up with we'll want to be very intentional with, though.</p>



<a name="235561308"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235561308" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235561308">(Apr 21 2021 at 18:46)</a>:</h4>
<p>In particular, it would be my expectation that a fixed period of time is not actually the right fit here; that makes adoption less likely. We <em>want</em> users using these features up until stabilization (or complete removal).</p>



<a name="235561365"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235561365" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235561365">(Apr 21 2021 at 18:46)</a>:</h4>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/241545-t-release/topic/testing-release-channel/near/235561048">said</a>:</p>
<blockquote>
<p>-preview components can't be required by dependencies unlike "preview" features, so that makes them somewhat different.</p>
</blockquote>
<p>Discussion so far has definitely centered on it being a workspace-local thing, which seems to mitigate this risk.</p>



<a name="235562016"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235562016" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235562016">(Apr 21 2021 at 18:51)</a>:</h4>
<p>Yeah, I'm imagining that the process for adding a feature to preview will come with something similar to the three conditions I outlined in <a href="https://internals.rust-lang.org/t/survey-of-high-impact-features/14536/1">https://internals.rust-lang.org/t/survey-of-high-impact-features/14536/1</a>, which I believe should mean that they shouldn't "entrench" the feature in the ecosystem. That said, I am still in favor of time-limiting the preview period, though with a caveat: at the end of the preview period, I think a stabilization decision should be made, with one of three possible outcomes:</p>
<ol>
<li>Stabilize, which will _also_ extend the preview period until the stabilization lands on stable.</li>
<li>Reject.</li>
<li>Bump, which is an _explicit_ decision to extend the preview period (again for a fixed amount of time).</li>
</ol>



<a name="235563570"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235563570" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235563570">(Apr 21 2021 at 19:01)</a>:</h4>
<p>I think that seems entirely reasonable. I will say that it is highly likely, I think, that there needs to be a (4) / intermediate state, which is that I would expect the preview period to also include ~continuous refinement to implementation as we learn things; at the very least, documentation.</p>
<p>I think it may be interesting to have an explicit requirement for pre-identified 'experimenters' who commit to preparing reports on their usage and experience.</p>



<a name="235907604"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/235907604" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#235907604">(Apr 23 2021 at 21:00)</a>:</h4>
<p>I wrote up an experimental implementation (just for Cargo for the time being) if anyone's curious. As I write there too, this would need to go through an RFC before it could actually land: <a href="https://github.com/rust-lang/cargo/pull/9401">https://github.com/rust-lang/cargo/pull/9401</a></p>



<a name="236585902"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/236585902" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#236585902">(Apr 28 2021 at 21:45)</a>:</h4>
<p>All right, some forward progress here. After discussing with the release team, I ended up taking the path of explicitly flagging "preview" features (only in Cargo for now) that would then be available on both beta and stable. I'd be curious to hear whether the general approach/implementation look sensible, and if so, I'll go ahead and write up an RFC: <a href="https://github.com/rust-lang/cargo/pull/9401">https://github.com/rust-lang/cargo/pull/9401</a></p>



<a name="236592750"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/236592750" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#236592750">(Apr 28 2021 at 22:54)</a>:</h4>
<p>Sorry, intended to post this to <a class="stream-topic" data-stream-id="246057" href="/#narrow/stream/246057-t-cargo/topic/unstable-on-beta">#t-cargo &gt; unstable-on-beta</a></p>



<a name="237381054"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241545-t-release/topic/testing-release-channel/near/237381054" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jon Gjengset <a href="https://rust-lang.github.io/zulip_archive/stream/241545-t-release/topic/testing-release-channel.html#237381054">(May 04 2021 at 19:04)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> I know you're busy with the 1.52/1.53 stuff, but just wanted to let you know that I wrote up an RFC for "preview features" in case you're interested: <a href="https://github.com/rust-lang/rfcs/pull/3120">https://github.com/rust-lang/rfcs/pull/3120</a></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>